Various communities and human connection networks have been generated on the Internet as Internet using people have greatly increased. Millions of communities with several to hundreds of thousands of members have been supported by large Internet portal sites.
Users as members of the above-noted communities or specific human networks have desired to know personal activities or events, and hence, systems for controlling a messenger or an Internet system and alerting corresponding events to respective clients have been developed. In this instance, the events represent tasks or activities that are generated when the users belonging to the corresponding groups or individual users perform community activities, and they include new articles registered by community members and new notice comments provided to community members by community managers. The events can be notified to the respective members by using a messenger, for example.
A conventional event alerting method includes an event alerting scheme based on a messenger having a large alerting system at the center of the messenger. The event alerting system manages a list of clients for receiving corresponding alerting messages and broadcasts corresponding events to the respective clients.
FIG. 1 shows a conventional messenger-based event alerting system, and FIG. 2 shows a flowchart for a conventional messenger-based event alerting method.
Referring to FIG. 1, the conventional messenger-based event alerting system includes a messenger-based event alerting server 110, a client list 120, and a plurality of clients 151, 152, and 153 belonging to various groups or communities 140, 150, and 160, which are connected to a network 130.
First, the conventional messenger-based event alerting system generally uses a method for using a client list 120 to be alerted in the format of a “reverse buddy.”
In detail and with reference to FIG. 2, in the conventional messenger-based event alerting method, an event generation status is checked in step S210, and when an event of A, B, or C is exemplarily generated, the messenger-based event alerting server 110 that is a central alerting system searches the client list in step S220. The event of A, B, or C is respectively transmitted to the searched clients in the group or the communities 140, 150, and 160 in step S230. A status of generating an additional event is checked in step S240, and when an additional event is found, the steps of S220 and S230 are repeated.
However, when the client list 120 is provided in a like manner of the conventional messenger-based event alerting system, first, the events are transmitted irrespective of the clients' 151, 152, and 153 online access states so that useless traffic may be generated, second, an overhead of always referring to the client list to be registered to each event is generated, and third, the capacity of the messenger server 110 for alerting events must be high enough to correspond to the product of the number of events and the average number of clients.
FIG. 3 shows a conventional event alerting system based on an event alerting unit, and FIG. 4 shows a flowchart for a conventional event alerting method based on an event alerting unit.
Referring to FIG. 3 and FIG. 4, the conventional event alerting system based on an event alerting unit includes an event alerting server 310 based on an event alerting unit, and a plurality of clients 241,242, and 243 belonging to various groups or communities 330, 340, and 350, which are connected to a network 320.
For example, when a user logs in to a server given in the format of a chat room and notifies an alert in the chat room in the above-described conventional event alerting system based on an event alerting unit, other users in the chat room are alerted.
In detail in the conventional event alerting method based in an event alerting unit, a status of generating an event is checked in step S410, and when an event of A, B, or C is generated, the central event alerting server 310 based in an event alerting unit only searches the logged-in clients 241 and 242 having entered the service in step S420. The event A, B, or C is respectively transmitted to the logged-in service subscribed client in step S430. A status of generating an additional event is checked in step S440, and when an additional event is found, the steps of S420 and S430 are repeated.
For example, when one client of the first community 330 alerts a request of generating an event A to the event alerting server 310, the event alerting server 310 notifies other clients of the first community 330 of the event A, and in this instance, no event is alerted to the clients that are not logged in. Further, the different event B or C is transmitted to the logged-in clients in other communities 340 and 350.
In the case of conventional management in the format of an event alerting unit, the clients in the online status are managed, differing from the above-described messenger based event alerting method to thus substantially reduce the load of the server, but when the number of clients is frequently changed or the number of clients for a specific event is very big, the process of other events may be delayed because of the corresponding event. Also, a server with a large capacity is required and traffic for event transmission provided to the central server cannot be ignored since the server alerts the event to the whole clients in a like manner of the messenger-based event alerting system.